The sample messaging system used in this article has the following design: an update stored procedure in AdventureWorks2008.Production.ProductModel starts up a service that initiates a conversation with a service in XCatMgmt. It does this by sending a message to the inbound work queue of XCatMgmt.
When the transaction surrounding the initial send is complete, Service
Broker transmits the message, signaling that a catalog change for an
AdventureWorks Cycles product model is ready for processing.
In response to the arrival
of this new message, Service Broker executes a stored procedure
associated with a catalog maintenance service for XCatMgmt,
known as its service program. This process is known as internal
activation; it is internal because the stored procedure resides in and
is activated by SQL Server.
Because a Service Broker
program might not always be a stored procedure, external activation is
also available when you use event notification with the QUEUE_ACTIVATION
event. You can create an event notification service and map it to your
Service Broker service and queue by using syntax such as the following:
CREATE QUEUE NotificationQueue
GO
CREATE SERVICE EventNotificationService
ON QUEUE NotificationQueue
([http://schemas.microsoft.com/SQL/Notifications/PostEventNotification])
GO
CREATE EVENT NOTIFICATION NotifyMe
ON QUEUE NotificationQueue FOR QUEUE_ACTIVATION
TO SERVICE 'EventNotificationService', 'broker-instance-guid'
Note that you need to retrieve your database’s Service Broker unique identifier and replace 'broker-instance-guid' with it for the example to work. To do this, you run the following query:
SELECT service_broker_guid
FROM sys.databases
WHERE NAME = 'AdventureWorks2008'
go
service_broker_guid
-------------------------------------
3036906E-8B9E-4266-A8C6-DD4E01B656CA
(1 row(s) affected)
Let’s return to the
sample system’s description. When the catalog maintenance service’s work
is done, it sends an acknowledgment message back to the sender’s
inbound queue.
To accomplish everything included in the design so far, you need to represent the following kinds of objects in the system:
Two types of messages: one defining product model catalog changes and one for acknowledgments
Two queues, one for each service
One contract that defines the message flow between the services
Two services, each representing an endpoint in the system
At least one conversation and its related conversation group
The following sections
describe how to define and build on all these new constructs, and you
learn how they work together in the orchestration of Service Broker
applications.
